home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 952 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.9 KB

  1. Path: fido.asd.sgi.com!austern
  2. From: davew@trigati.cs.haverford.edu (David G. Wonnacott)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Rationale behind disallowal of non-const r
  5. Date: 03 Apr 1996 09:24:06 PST
  6. Organization: Bryn Mawr and Haverford College NetNews
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <DAVEW.96Apr3110726@trigati.cs.haverford.edu>
  9. References: <DAVEW.96Mar27195129@trigati.cs.haverford.edu>
  10.     <4jevb1$kkp@engnews1.Eng.Sun.COM>
  11. NNTP-Posting-Host: isolde.mti.sgi.com
  12. X-Original-Date: 03 Apr 1996 16:07:26 GMT
  13. In-Reply-To: clamage@Eng.sun.com's message of 28 Mar 1996 21:16:23 GMT
  14. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  15.     iQBVAwUBMWK0N0y4NqrwXLNJAQFM/gH/ThPv7xpC30N7kE4CYiFWFIslPGjG/fE5
  16.     vt/psEtAebBqaQrzsEL/nWducvg8Iir6Q9tASDJIGPFUEI8PCbffJQ==
  17.     =/h7W
  18. Originator: austern@isolde.mti.sgi.com
  19.  
  20. In article <4jevb1$kkp@engnews1.Eng.Sun.COM> clamage@Eng.sun.com (Steve Clamage) writes:
  21.  
  22.    From: clamage@Eng.sun.com (Steve Clamage)
  23.    Newsgroups: comp.std.c++
  24.    Date: 28 Mar 1996 21:16:23 GMT
  25.  
  26.    In article 96Mar27195129@trigati.cs.haverford.edu, davew@trigati.cs.haverford.edu (David G. Wonnacott) writes:
  27.    >
  28.    >I am looking for an explanation for the rationale behind the decision
  29.    >of the standards committee to disallow the binding of a non-const
  30.    >reference to an rvalue.
  31.  
  32.    The basic reason is that it usually is an error.
  33.    ...
  34.  
  35.    Yes, there are times when you would like to be able to bind an rvalue
  36.    to a non-const reference, since the only things you care about are
  37.    sure to happen anyway.        ...           I believe the C++
  38.    committee looked for ways to allow this binding of an rvalue to a non-const
  39.    reference in cases where the results were what was intended, but failed to
  40.    find a good way to define those cases.
  41.  
  42. What ever happened to "make it legal but recommend a warning?"  My
  43. understanding of "illegal" is that the compiler should refuse to
  44. compile the program.  I agree that the vast majority of occurances of
  45. a non-const reference to an rvalue would be due to programmer errors.
  46. But then again, so are many cases of "if (x=5) ...".
  47.  
  48. As I said, we make use of this all over the place, and its going to be
  49. a real problem for us if this produces an error from most compilers.
  50.  
  51. We have a class for which (1) copying can be expensive, and (2) there
  52. are some operations that extract information only after having a side
  53. effect that can not be avoided (without copying).  Imagine if we could
  54. do ++i but not i+1 for integers, and that copying them was expensive.
  55. Suppose we we have a library that provides functions f1 and f2:
  56.  
  57.    int f1()         { ... }
  58.    int f2(int &i)   { ++i; return i; }
  59.  
  60. (note that we copy the return values, but not the argument - it turns
  61. out that we are more concerned with unnecessary copying for arguments
  62. than return values).  The user of our library can then use y=f2(x),
  63. and x will be incremented, and y will take on the new value.  We'd
  64. like to let them use y=f2(f1()), to make y take on the value that is
  65. one more than the value returned by f1().  The side-effect that was
  66. performed on the object returned from f1 is lost, but we don't care.
  67.  
  68. I don't see any way of writing this without either (a) binding a
  69. non-const reference to an rvalue, (b) forcing the user of our library
  70. to set up an explicit temporary variable every time they use this
  71. construct, or (c) giving up on avoiding this overhead and using call
  72. by value for f2, or (d) doing something really brain-damaged like:
  73.  
  74.    int f2(const int &j) { int &i = (int &)j; i++; return i; }
  75.  
  76. But (a) is illegal, (b) is unreasonably inconvenient for our users,
  77. (c) is inefficient, and (d) makes me queasy.
  78.  
  79. Dave W
  80. ---
  81. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  82.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  83.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  84.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  85.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  86. ]
  87.